Summary Most project businesses we work with have the same quiet problem. The project team plans and tracks work in Dynamics 365 Project Operations. The finance team bills, buys and closes the books in Dynamics 365 Business Central. Everything the project team decides has to be typed again by finance. The two teams spend their week checking each other’s numbers. At CloudFronts we closed that gap with plugins: small automatic helpers that sit inside Project Operations and act the moment someone saves a record. When a project, a plan, a timesheet or an invoice is saved, the helper creates the matching record in Business Central and writes the Business Central reference back on the project. This integration is available as the PO-BC Integration Module 2.0 on Microsoft Marketplace. To show how this works in practice, we ran a real example through our demo environment: CloudFronts – Smart Office Rollout, Mumbai, a short project to fit out a new office floor. Every screenshot in this post comes from that one project. Table of Contents Summary→ Business Challenges→ The Idea in Plain Words→ Walkthrough: The Mumbai Office Rollout→ What Moves, and When→ The Safety Nets→ What We Learned Building It→ Business Impact / Key Takeaways→ Questions We Get Asked→ Conclusion / Final Thoughts→ Call to Action / Connect With Us→ Business Challenges Picture the Mumbai office rollout without any connection between the two systems. Monday. The project manager sets up the project, splits it into four tasks and plans 104 hours of work in Project Operations. Finance is told about it in an email. Tuesday. Finance creates the same project in Business Central, retypes the four tasks, and builds a budget from a spreadsheet the project manager sent over. One task name is spelt differently. Nobody notices. Wednesday. The plan changes: cabling needs an extra day. Project Operations is updated. The budget in Business Central is not. Thursday. Twenty desks are taken from the warehouse for the new floor. The site team records it in Project Operations. Business Central still believes the desks are on the shelf. Friday. Finance asks why the project margin looks wrong. Two people spend the afternoon comparing screens. None of this is anyone’s fault. Each system is doing its job. They just do not talk to each other. The Idea in Plain Words A plugin is a small piece of code that lives inside Project Operations and wakes up at a specific moment, for example when a project is saved or a timesheet is approved. Ours does three things each time it wakes up: It reads what just changedThe project name, the customer, the task, the hours, the item and quantity: whatever finance would otherwise have to retype. It creates or updates the same record in Business CentralIt signs in to Business Central with its own dedicated account, not a person’s login, so it keeps working when people change roles or leave. It writes the answer backBusiness Central replies with its own reference, such as a project number or an invoice number. That reference is saved on the Project Operations record, so both teams can always find the matching record in the other system. 💡Why a plugin and not a scheduled sync? A scheduled sync runs every hour or every night and moves whatever has changed. A plugin acts on the exact save, so Business Central is updated within seconds, and only the record that changed is sent. It is also packaged with the rest of the Project Operations setup, so moving it from the test system to the live one is a single, repeatable step. Walkthrough: The Mumbai Office Rollout Here is the same week again, this time with the integration switched on. The customer is CloudFronts Technologies, already known to Business Central as customer C00310. The work is 40 new workstations, meeting-room screens and office Wi-Fi. The customer account, integrated to Business Central with its customer number sent back. Step 1: The Project Manager Creates the Project, Once The project manager creates the project in Project Operations with a name, the customer, a start date of 12 October and a finish date in December. The project code is left blank because nobody knows it yet. A few seconds after saving, the code J00700 appears in the Project Code field. That number came back from Business Central. The project integrated to Business Central. The project code J00700 was filled in automatically. Step 2: The Tasks Follow The project manager adds four tasks in the project plan: Site Survey and Floor Plan, Network Cabling and Wi-Fi, Workstation and Screen Installation, and Testing and Handover. Each one is created under project J00700 in Business Central with the same name and dates, numbered 1272 to 1275. Finance did not open anything. Step 3: The Plan Becomes the Budget Next, the project manager assigns a named person to each task: 16 hours for the survey, 40 for cabling, 32 for installation and 16 for testing and handover. The integration turns that plan into budget lines in Business Central, one line per working day per person, so finance sees not only how much work is planned but when it falls. Weekends are skipped automatically. Resource assignments from Project Operations, turned into daily planning lines in Business Central. ⓘWhy one line per day? A single line of "104 hours" tells finance the total but nothing about timing. Daily lines let finance see cost landing in October versus November, which matters at month end. If the plan changes, the same lines are updated, not duplicated. Step 4: Real Work and Real Material Arrive as Actuals On 12 October, the consultant logs a day on the site survey: "Walk-through of the new floor; desk layout and cable routes agreed with facilities." A week later, the site team records 20 ATHENS desks taken from the Main Warehouse for the installation task. The integration does not send rough drafts. Time and material only go to Business Central once they are submitted for approval, and the … Continue reading No More Retyping: How We Connected Project Operations and Business Central with Plugins →

Summary A Houston based cybersecurity company came to us with a familiar complaint. Their sales leaders had everything they needed sitting in Dynamics 365, yet every Monday review still started in Excel. They asked for two things: their reports laid out the way they actually think about the business, and an assistant they could simply ask questions. We delivered both in one app, built with Power Apps Code Apps on top of the CRM data they already had. In This Blog What was slowing the sales team down What we built for them, screen by screen The AI agent we added so leaders can just ask What changed for the business How to tell if this approach fits your team Table of Contents Summary→ Business Challenges→ What We Built→ The AI Agent→ How It Works→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges Nothing was broken. The data was good and the team was using the CRM. The trouble was getting answers out of it quickly. A standard view shows you a list of records, which is great when you are working a lead. It is far less helpful when the sales director wants to know how many leads turned into real opportunities this quarter, and who brought them in. So the weekly routine looked like this: Open one view, then another, then a third, to piece the funnel together. Export everything to Excel and rebuild the same pivot table as last week. Walk into the meeting with numbers that were already a few days old. What the team really wanted was simple: better looking reports they could read at a glance, and an AI agent alongside them to answer the questions the reports did not cover. Before Several views to see one picture Weekly exports and pivot tables Numbers out of date by meeting time After Key numbers on the first screen One set of filters for everything Answers by simply asking What We Built Power Apps Code Apps let us design the screens completely from scratch while still reading the same Dynamics 365 data, live. Think of it as a new front door to the CRM, arranged around the questions the leadership team asks every week. Nothing was copied or moved anywhere else. The app has four pages, and they all work the same way, so people only learn it once: LeadsWhere new interest comes from and how much of it qualifies. OpportunitiesThe live pipeline, in the order leadership reviews it. SalesWhat has closed and how the team is tracking. ProjectsWhat happens after the deal is won, from Project Operations. Each page opens with the headline numbers, such as total leads, open leads, qualified leads and the qualification rate. Below that sits a single filter bar for owner, status, account, dates and search. Change one filter and every number, chart and list on the page updates with it. The summary page: headline numbers, a trend over time, and breakdowns by customer, source and owner. Shown with demo data. When a chart raises a question, the detail page shows the actual records behind it, already filtered the same way. The detail page, using the same filters as the charts. Shown with demo data. The AI Agent The second half of the request was an assistant. Code Apps do not include one, so we built our own AI agent and placed it in a side panel inside the app. Leaders type a question the way they would ask a colleague, and the agent answers from the live CRM data. Questions like which lead came in most recently, which owner has the best qualification rate this quarter, or which accounts have open deals but no new leads. Things that used to need an export now take a few seconds. In practice this is the feature people mention first when they talk about the app. Want to see how the agent itself was built? We covered that in our earlier post on how we connected an Azure AI Foundry agent to Dynamics 365 for the same client. The AI agent answering a question about the most recent active lead. Shown with demo data. How It Works You do not need to be technical to follow this. There are really only four moving parts. Step oneSign in as usualSame Microsoft account, nothing new to remember Step twoPower Apps opens the appInside the platform you already use Step threeYour custom screensNumbers, charts and lists in your layout Step fourLive CRM dataAlways current, never copied How the pieces fit together, including the AI agent. A few things matter here for the business. People only see the records they were already allowed to see in Dynamics 365. There is no separate portal to pay for or look after. And because the app sits inside a normal Dynamics 365 solution, moving it from testing to live was as routine as any other release. Worth knowing before you start Users cannot save their own personal views in this kind of app, so the filters need to be planned with the team up front. Very heavy reporting may still be better in Power BI. And it is built by a developer rather than configured, so plan for someone to own small changes after go live. Impact One place for the whole story. Leads, pipeline, sales and delivery sit side by side instead of in four corners of the CRM. Questions get answered on the spot. The AI agent handles the ones nobody built a chart for. No new licences or logins. It runs on what the client already owned, under the security they already manage. Is This Right for You? Code Apps are not a replacement for everything in Dynamics 365. This is how we usually explain the choice to clients. This projectCode App Standard Dynamics 365 app Power Pages Who it is for Your own team, when they need a view built around their role Your own team, for everyday record work … Continue reading How a U.S. Industrial Cybersecurity Company Built a Custom Sales Portal with Power Apps Code Apps →

Please find this CloudFronts Product at – Integration Module between Dynamics 365 Project Operations and Finance & Operations | Microsoft Marketplace Summary Manually creating custom fields in Dynamics 365 Project Operations across multiple environments is time-consuming, error-prone, and blocks automation. This challenge can be addressed by using Dataverse Metadata OData APIs to programmatically create, update, and publish custom attributes during deployment. The process involves authenticating with Azure AD, calling Metadata API endpoints to create attributes, and publishing the changes with the PublishXml action, all through a fully automated approach. As a result, organizations achieve zero manual intervention, environment consistency, integrations, reduced human error, and a reusable framework that can be applied across all field types. Please find this CloudFronts Product at – CloudFronts – PO-FO Connector Table of Contents Introduction Business Challenge Why OData Metadata APIs? Implementation Procedure End-to-End Working Why This Approach Works Real-World Use Cases Conclusion Introduction When integrating external business applications with Microsoft Dynamics 365 Project Operations, it is common to discover that every customer requires additional fields to store information originating from ERP systems, manufacturing platforms, pricing engines, or product lifecycle management systems. For one of our internal projects & Prospect PoC implementing product-centric integrations, we needed a way to provision these custom fields automatically during deployment. Traditionally, creating new columns involves opening the Power Apps Maker Portal, adding fields manually, publishing the table, exporting a solution, and repeating the same process across multiple environments. While this approach works for occasional changes, it quickly becomes a bottleneck for automated deployments and CI/CD pipelines. The Solution: CloudFronts implemented a fully automated approach using the Dataverse Metadata OData APIs, enabling integration deployments to create and publish new Project Operations attributes programmatically. Business Challenge The customer’s integration platform exchanged large volumes of product and financial information with Dynamics 365 Project Operations. Each deployment required several custom attributes such as: Product identifiers ERP reference numbers Financial synchronization IDs External integration keys Processing status fields Creating these fields manually across Development, Test, UAT, and Production introduced several challenges: Manual configuration effort (time-intensive) Human errors (typos, misconfigurations) Environment inconsistencies (field variations across environments) Longer deployment windows Difficult CI/CD automation The Objective: Allow the deployment process itself to provision any missing attributes before importing data, eliminating manual touchpoints entirely. Why OData Metadata APIs? Most developers use the Dataverse Web API for CRUD operations on business records. However, Dataverse also exposes Metadata APIs, allowing developers to programmatically manage the schema itself—including tables, columns, relationships, and option sets. Microsoft documents creating attribute metadata by posting to the Attributes navigation property of an entity definition. This means integrations can: Create new columns dynamically Update existing metadata Publish customizations instantly Eliminate manual portal work Scale across multiple environments consistently Unlike traditional manual solutions, the Metadata API approach is fully programmable, auditable, and repeatable. Implementation Procedure Step 1 – Authenticate with Dataverse The integration first authenticates against Azure Active Directory using an application registration and retrieves an OAuth Bearer Token. That token is then supplied with every Metadata API request. Authentication Flow: Register application in Azure AD Configure permissions for Dataverse access Obtain OAuth 2.0 Bearer Token Include token in Authorization header for all API calls Step 2 – Creating a Custom Attribute The Dataverse Metadata API exposes the following endpoint for creating new attributes: POST /api/data/v9.2/EntityDefinitions(LogicalName=’msdyn_contractlineinvoiceschedule’)/Attributes Instead of creating business records, this endpoint creates metadata at the schema level. For this implementation, we created a new string attribute with the following properties: Schema Name: int_fnoid Display Name: FNO ID Data Type: String Maximum Length: 100 The request body uses the Microsoft.Dynamics.CRM.StringAttributeMetadata type together with standard metadata properties such as SchemaName, DisplayName, RequiredLevel, and MaxLength. Supported Metadata Types: Microsoft supports multiple metadata types through the same endpoint including String, Decimal, Boolean, Picklist, DateTime, Lookup, Currency, and more. Step 3 – Publishing the Metadata Creating an attribute does not immediately make it available. Like changes made through the Power Apps Maker Portal, metadata created through the Web API must also be published. This is accomplished using the PublishXml action. POST /api/data/v9.2/PublishXml The request specifies the entity to publish. After publishing completes successfully, the new attribute immediately becomes available throughout Dynamics 365. End-to-End Working The complete deployment process follows these steps: Integration authenticates with Azure AD. Dataverse access token is generated. Metadata API checks whether the required attribute exists. Missing attributes are created automatically. PublishXml is executed. New attributes become available. Product synchronization begins. External systems start populating the new fields immediately. Integration Points: This Attribute creation setup can be utilized across Logic Apps, Plugins, Azure Functions, and other Custom Workflows. Why This Approach Works ✓ Fully Automated Deployments No manual intervention is required when new integration fields are introduced. ✓ Environment Consistency Development, Test, UAT, and Production remain synchronized because every environment provisions the same metadata through code. ✓ CI/CD Friendly Metadata creation can be incorporated directly into Azure DevOps or GitHub deployment pipelines. ✓ Reusable Framework The same framework can create String, Decimal, Currency, Lookup, Date, Option Sets, and Boolean fields. ✓ Reduced Human Error Eliminates mistakes caused by manual customization and inconsistent naming conventions. ✓ Prevented Duplication Eliminates duplication of records, preventing system garbage in the database. Real-World Use Cases Use Case 1: PO-FO Integration (Project Operations to Finance Operations) For enterprises running integrated Project Operations and Finance Operations modules, this approach ensures that: ERP reference numbers sync automatically across all linked tables Financial synchronization IDs are created before data import External integration keys propagate consistently Processing status tracking fields exist in all dependent entities No manual re-entry of attribute definitions across environments Impact: Reduces deployment time from hours to minutes, eliminates sync mismatches between PO and FO modules, and enables real-time data reconciliation. Conclusion For an internal project and prospect PoC implementing product-centric integrations, automating metadata creation transforms what was previously a manual administrative task into a repeatable deployment process. Rather than relying on solution imports or manual customization through the Power Apps Maker Portal, integrations can now provision required Project Operations attributes on demand … Continue reading Automating Attribute creation in D365 Project Operations, Using Dataverse OData Metadata APIs for an Internal Project Operations–Finance & Operations Integration →

Summary SIP Industries is a Houston-based manufacturer of engineered components. Every new part it makes goes through a six-stage New Product Development (NPD) Business Process Flow in Dynamics 365. Most of the people who approve those stages never open the CRM. They include plant engineers and QA inspectors in India, the U.S. engineering team and customer reviewers. They replied by email, and the CRM team typed each reply into the NPD record and then clicked Next Stage by hand. We replaced that manual relay with three Power Automate flows, plus a small daily reminder flow. Each approver gets an email with one button, which opens a pre-filled HTML form that needs no login. The flows save the answers to Dataverse and move the stage forward once its conditions are met. Nobody keys in approvals or moves stages by hand any more. SI SIP IndustriesEngineered components manufacturer, Houston, Texas Industry Manufacturing Region United States StackDynamics 365 SalesPower AutomateMicrosoft DataverseSharePoint Table of Contents Summary→ Business Challenges→ Solution Overview→ Technical Approach→ Business Impact→ Conclusion→ Connect With Us→ Business Challenges SIP already had a working NPD Business Process Flow on a custom New Product Development table. The stage design was sound. The time went into one recurring loop that the CRM team ran by hand for every stage of every part. New Product Development View A CRM user emailed the approver for that stage and attached or linked the latest drawing The approver replied in the thread, often with a one-line "go ahead" and an estimate buried in the text The CRM user read the reply and typed the decision, notes and dates into the NPD record The CRM user opened the Business Process Flow and clicked Next Stage The CRM user emailed the next team to tell them it was their turn That loop broke down in four specific places. Licensing the approvers was never realistic. A customer reviewer who signs off a sample twice a year does not need a Dynamics 365 seat, training and a password to remember Some stages close on more than one decision. Feasibility needs feasibility approval, engineering approval and a created engineering drawing. First Article Inspection needs both the India QA team and the U.S. engineering team. These approvals arrived in any order and someone had to keep track of which were still missing Drawing approvals stalled for weeks. Nothing reminded the reviewer, so follow-up depended on a CRM user remembering to chase The audit trail lived in personal mailboxes. Opening the NPD record told you the current stage, not who approved it or when Solution Overview We put an email-driven approval layer on top of the existing NPD process. When an NPD record reaches a stage, Dynamics 365 emails the approver for that stage. The email is written for that stage, so a Pattern request shows pattern details and an inspection request shows inspection details. It ends with one button. Engineering Approval Request Received in Outlook The button opens a web form in the approver’s browser, already filled in with whatever the NPD record holds. The form lists the product’s SharePoint documents and accepts new uploads. The approver picks a decision, adds notes and submits. Feasibility Approval Form Dynamics 365 then saves the answers into the right NPD fields. It moves the process to the next stage if that stage’s conditions are now complete, and the next approver gets their email. A rejection or a "Requires Changes" answer keeps the record in its current stage and notifies the NPD team instead. ⓘWho still uses the CRM The NPD team still works in Dynamics 365 and can set any field directly. The automation responds to changes made in the CRM in the same way as changes made through a form. Technical Approach Architecture at a Glance TriggerNPD record savedStatus or an approval field changes Flow 1Send Approval EmailTracked email with a stage-specific button Flow 2Show Approval FormReturns pre-filled HTML for the stage Flow 3Save Approval ResponseWrites answers and uploads to Dataverse and SharePoint DataverseBPF advancesNext stage starts and Flow 1 fires again These three flows run the entire approval loop, and the loop closes itself. When Flow 3 saves an answer, the NPD record changes, and that change triggers Flow 1 again. Flow 1 then either moves a stage whose conditions are now all met or sends the next approver their email. Alongside the loop, a separate reminder flow runs once a day and chases open drawing approvals. Six Stages, Eight Forms New Product Development Form Stage Approver Form Captures Stage Closes When Feasibility Feasibility team, Engineering team Feasibility approval, engineering approval, notes, estimated development timeline, estimated tooling cost Both approvals recorded and engineering drawing created Drawing Approval Drawing reviewer Drawing received, sample required, feedback, approval Reviewer approves on the form Pattern Plant and tooling team Pattern status, foundry, notes Pattern Status set to Ready For Inspection First Article Inspection India QA, U.S. engineering FAI approval and date, sample sent to U.S., shipment date, U.S. approval and comments Both India and U.S. approvals recorded Customer Approval Customer Yes, No or Requires Changes, with the approval date set automatically Customer answers Yes Production Production team Release notification Final stage NPD stages, approvers and the condition that closes each one Six stages produce eight forms because two stages have two separate approvers. Feasibility has one form for the feasibility team and one for engineering. First Article Inspection has one for India QA and one for U.S. engineering. Each form is identified by a stage key: feasibility, engineering, drawing, pattern, fai, fai_us, customer and production. Each form shows only the fields that apply to the record. The India FAI form asks whether a sample was sent to the U.S. only when the drawing reviewer marked a sample as required. It asks for the shipment date only after the sample has gone. Why the Form Lives Inside Power Automate Criteria Power Pages Canvas App Our choiceHTML form from Power Automate Approver opens it without signing in ✗ ✗ ✓ No … Continue reading How a U.S. Castings Manufacturer Saved Time by Updating Dynamics 365 Without Logging Into CRM →

At a Glance A client in Abu Dhabi discovered more than 400 posted G/L entries with incorrect dimension values. Using Dimension Correction in Microsoft Dynamics 365 Business Central, the finance team was able to correct the dimension values in bulk without creating reversal or adjustment entries. The corrections could be validated, audited, reviewed, and undone, providing a controlled approach to fixing posted transactions. However, it is important to note that Dimension Correction applies to G/L entries only; related sub-ledger entries retain their original dimensions. Table of Contents Introduction Why Dimension Errors Happen in the First Place What Dimension Correction Actually Does Setting Up Before the First Correction Step 1: Starting the Correction from the Ledger Step 2: Selecting Entries in Bulk Step 3: Defining the Dimension Changes Step 4: Validating Before You Run Step 5: Running the Correction Step 6: Reviewing, Undoing and Auditing A Note on Cost Accounting The Outcome Best Practices We Recommend Conclusion Frequently Asked Questions About the Author Introduction Dimensions are what turn a general ledger from a list of numbers into something management can actually use. A single expense posting tells you how much was spent; the dimensions on that posting tell you which department spent it, on which project, at which location. When dimensions are right, reports by cost centre, business unit or project take seconds to produce. When they are wrong, every one of those reports quietly becomes unreliable. That was the situation one of our clients in Abu Dhabi found themselves in. During routine month-end review, their finance team noticed that a large group of posted transactions carried the wrong dimension values. Some entries were tagged to the wrong department, others to the wrong project, and a few had no value at all where one was expected. By the time the pattern was traced, more than 400 general ledger entries were affected. Reversing and re-posting each transaction was not an option. It would have doubled the number of entries in the ledger, cluttered the audit trail and taken days of effort. Editing entries one at a time was equally impractical. Instead, we used the Dimension Correction feature in Microsoft Dynamics 365 Business Central to fix all of them in a controlled, bulk operation, without touching the amounts or the accounts. This blog walks through how the feature works, how we applied it for this client, and what to keep in mind before you run a correction in your own environment. Why Dimension Errors Happen in the First Place In our experience, incorrect dimensions rarely come from a single cause. For this client, the errors came from a mix of everyday situations that most finance teams will recognize: 1. Default dimensions not updated after an internal restructuring, so new transactions kept inheriting the old department code. 2. Manual journal entries where users picked a similar-looking value from the lookup list. 3. Recurring journals that were copied forward month after month with an outdated project code. 4. Imported data from a spreadsheet where the dimension column was shifted by one row. None of these errors affected the trial balance. The debits and credits were correct and the accounts were correct. What was wrong was the analytical layer on top, which meant that department-wise P&L and project cost reports no longer matched reality. What Dimension Correction Actually Does Dimension Correction lets an authorized user change the dimension values on general ledger entries that have already been posted. It does this without creating new journal lines, reversals or adjustment postings. The amounts, dates, document numbers and G/L accounts stay exactly as they were; only the dimension set linked to each entry is updated. Every correction is recorded as its own document with a description, a status and a list of the entries it touched. That means auditors and finance managers can always see what was changed, when, and why. Important limitation The correction applies to G/L entries only. Related sub-ledger entries, such as customer, vendor, item or fixed asset ledger entries, keep their original dimensions. Since the purpose of the feature is accurate financial reporting, this is by design, but it is worth communicating to anyone who reports from sub-ledgers. Setting Up Before the First Correction Before our client’s finance team ran anything, we put two controls in place. 1. Decide who can correct dimensions Access to the feature is governed by the D365 DIM CORRECTION permission set. We assigned it only to the finance controller and one senior accountant. Users with this permission can create, run and undo corrections, so it should not be handed out broadly. 2. Protect dimensions that should never change On the Dimension Correction Settings page, you can list dimensions that are blocked from correction. For this client, we blocked the dimension used for statutory entity reporting, since any change there needed a formal adjustment rather than a re-tag. Step 1: Starting the Correction from the Ledger A correction can be started from two places: 1. General Ledger Entries page, using the Correct Dimensions action. This is the most flexible starting point when the affected entries are spread across many postings. 2. G/L Registers page, by selecting a register and choosing Correct Dimensions. This pre-loads all entries from that register and is useful when a single batch posting went wrong. Because the client’s 400+ entries came from different journals and dates, we started from the General Ledger Entries page. The first thing we filled in was the Description field, with a note explaining the reason for the change and a reference to the internal approval. It takes ten seconds and saves a lot of questions six months later. General Ledger Entries page showing the Correct Dimensions action. Step 2: Selecting Entries in Bulk This is where the feature really earns its place. Instead of picking entries one by one, the Selected Ledger Entries FastTab offers several ways to build the list: Option How we used it Add by Filter Filtered on G/L account range and posting date range to pull … Continue reading How an Abu Dhabi-Based Diversified Holding Company Corrected Mis-Tagged Ledger Entries in Dynamics 365 Business Central →

Summary This solution is being implemented initially for the Chart of Accounts of an Emirates-based firm , where significant updates are required across the existing G/L Account master. The objective is to provide Finance users with a simpler and more familiar way to review and maintain supported records through Excel, reducing the dependency on technical users for routine maintenance activities. Although the current implementation focuses on the Chart of Accounts, the approach is not limited to G/L Accounts and can be extended to other supported master data, such as Customers, Vendors, Items, and similar records. By providing an Excel-based alternative for suitable maintenance scenarios, the solution reduces the need to use Configuration Packages for every routine update while allowing technical teams to focus on complex development, integrations, automation, and customization activities. Table of Contents Introduction Understanding the Business Requirement The Traditional Approach The Business Problem The Excel-Based Solution Using Excel Integration Selecting the Required G/L Accounts Reviewing Existing Data Updating Supported Fields Publishing Changes Verifying the Changes Implementation Approach Moving Bulk Maintenance Toward Functional Users Business Impact Important Considerations Frequently Asked Questions Conclusion Introduction The Chart of Accounts is one of the core components of financial management in Microsoft Dynamics 365 Business Central. As part of the current implementation for an Emirates-based firm, significant updates are required to the existing Chart of Accounts to align the financial structure with the organization’s evolving reporting, accounting, and operational requirements. Since the required changes involve a large number of G/L Accounts, updating each account individually within Business Central would be repetitive and time-consuming. The volume of changes creates a requirement for a more efficient approach that allows multiple existing records to be reviewed and updated in a structured manner. Traditionally, Configuration Packages can be used to perform bulk data updates in Business Central. While this provides a powerful mechanism for data migration and bulk maintenance, routine updates may still require technical involvement and additional configuration steps. For the current Chart of Accounts requirement, the objective is to provide Finance users with a simpler and more familiar method for making supported bulk changes. The Key Question: Can Finance users efficiently review and update a large number of G/L Accounts through a familiar Excel-based interface, while reducing the need for technical assistance for routine bulk maintenance activities? To address this requirement, the proposed approach uses the Microsoft Dynamics 365 Business Central Excel integration for supported bulk maintenance activities. Although the initial implementation is focused on the Chart of Accounts due to the significant updates required for the Emirates-based firm, the same approach can also be applied to other supported master data, such as Customers, Vendors, Items, and other relevant records, where similar bulk maintenance requirements arise. Understanding the Business Requirement During the implementation, the consultant was faced with a practical challenge: the Finance team needed to make a significant number of changes to the existing Chart of Accounts, but updating each G/L Account individually in Business Central would require considerable manual effort. The consultant also needed a solution that Finance users could work with directly, without having to depend on the technical team for every routine change. The Excel integration provided a way to address this issue by allowing the consultant to work with the relevant G/L Account data in a familiar spreadsheet environment. Instead of opening and modifying accounts one by one, the required records could be brought into Excel, reviewed together, and the necessary values could be prepared or updated in bulk. This made the large-scale Chart of Accounts maintenance activity more manageable and significantly reduced repetitive manual work. How the Requirement Was Resolved: The consultant can use the Business Central Excel integration to provide Finance users with a structured way to work with supported G/L Account data in bulk. This allows multiple records to be reviewed and updated through Excel rather than requiring individual changes within Business Central for every account. This approach also addressed the dependency between the Finance and technical teams. Finance users can handle suitable routine master-data maintenance themselves, while the technical team remains available for activities that genuinely require technical expertise, such as complex customizations, integrations, automation, troubleshooting, and development. Although the immediate problem was related to the Chart of Accounts, the solution is not limited to G/L Accounts. The same concept can be applied wherever Business Central supports the relevant Excel-based maintenance capability, including other master data such as Customers, Vendors, Items, and similar records. This makes the approach useful beyond the immediate implementation and provides a repeatable method for handling future bulk maintenance requirements. The Traditional Approach Before considering the Excel-based approach, the consultant could use Configuration Packages to perform bulk updates to the Chart of Accounts. Configuration Packages are a standard and powerful Business Central capability for importing, exporting, and managing data across Business Central tables and remain particularly useful for data migration, initial configuration, and structured data-import scenarios. However, for the current requirement, the Finance team needed to make a significant number of changes to existing G/L Accounts. Using a Configuration Package for every such change could require additional preparation and involvement from a technical or experienced Business Central user. This created an additional dependency for what was essentially a routine master-data maintenance activity. The consultant therefore had to consider not only how the data could be updated in bulk, but also how the process could be made easier for the Finance team while maintaining appropriate control over the data. Finance Identifies Changes → Prepare Update Data → Technical Assistance → Configure Package → Import & Validate → Finance Verification This approach works well when there is a genuine requirement for structured data migration or when multiple related tables and fields need to be handled together. However, for repetitive updates to existing master records, it can result in additional steps that are not always necessary for the Finance user’s immediate requirement. The objective, therefore, was not to replace Configuration Packages altogether. Instead, the consultant identified an opportunity to use the Business Central Excel … Continue reading How an Abu Dhabi-Based Diversified Holding Company Simplified Master Data Maintenance in Dynamics 365 Business Central Using Excel →

Summary This post started with a real request. A Netherlands-based sustainability certification company that runs its certification programme on Dynamics 365 wanted the certificates it issues to come straight out of the CRM, instead of being rebuilt by hand in a document every time. The problem itself is common. Certification bodies, testing labs and manufacturers issue certificates every day, and in most organisations that still means a Word template, a lot of copy and paste, and a PDF sent by email. The data that belongs on the certificate already lives in Dynamics 365, so why can’t the certificate come straight from the record? In this blog we build exactly that. A Generate Certificate button on a Dataverse form calls a Custom API, a small plugin hands the data to an Azure Function, and a branded, print-ready PDF comes back in about four seconds. Today the PDF is stored on the record as a base64 string, previewed and downloaded right on the form. Because the renderer only returns bytes, sending the same file to SharePoint, Azure Blob Storage or an email is a change to one step, not a rebuild. In This Blog This blog walks through a complete, working certificate generator for Dynamics 365, from the data model to the button, using a product certification scenario. The Scenario: A certification body issues product certificates and needs every one to be accurate, branded and traceable. The Approach: Keep the data in Dataverse, render the PDF in an Azure Function, and connect them with a Custom API. The Action: One click on the form produces the certificate, stores it on the record and shows a live preview. The Outcome: No manual formatting, no retyping, no per-document licence fees, and a design that can later publish to SharePoint or Blob storage. Table of Contents Summary→ In This Blog→ Business Challenges→ Solution Overview→ Technical Approach→ Impact→ Conclusion→ FAQ→ Get in Touch→ Business Challenges A certificate is a legal statement: this product, made by this company, meets this standard, from this date to that date. When it is produced by hand, the risks are small individually and expensive together. Copy and paste errors. Product names, model numbers and expiry dates are retyped from the CRM into a document. One wrong digit on an issued certificate means a reissue and an awkward conversation. Template drift. Every coordinator keeps a slightly different copy of the Word template, so logos, wording and signatories quietly diverge. No trail. Once the PDF leaves someone’s desktop there is no record of which version was produced, when, or from which data. Platform limits. Dataverse plugins run in a sandbox that cannot lay out and paginate a PDF, and a JavaScript-only solution would expose service keys to every user’s browser. Before Word template and email Values retyped from the record Layout depends on who made it File lives in someone’s Downloads folder No link back to the CRM record After One click on the record Values read directly from Dataverse One design, driven by configuration PDF stored on the record with its hash Preview and download on the same form Solution Overview The demo uses a fictional certification body, Contoso Product Assurance, which certifies products made by manufacturer accounts against its own published standards. The whole flow runs from a single button: FormGenerate CertificateCommand bar button on the Product Certificate form DataverseCustom APIBound action cf_GenerateCertificate PluginCollect the dataCertificate, product, holder and standard AzureRender the PDFFunction returns the file as base64 RecordStore and previewBase64 saved, previewed and downloadable Architecture One click on the form, one PDF back on the record. The dashed box is where SharePoint, Blob storage or email plug in later. Data modelThree custom tables (Standard, Product, Certificate) plus the standard Account table for manufacturers. Custom API and pluginOne server-side entry point. The function key never reaches the browser. Azure FunctionA .NET 10 renderer on the Consumption plan. Vector PDF, embedded fonts, QR code. Form experienceGenerate and Download buttons plus an inline PDF preview panel. A certificate generated from Dataverse data. Every value on it comes from the record; nothing is typed. Technical Approach 1. The data model Everything lives in one solution, CFCertificateGeneration, so it moves between environments as a unit. Table Purpose Key columns Certification Standard What products are assessed against Code, Version, Default Scope, Validity (Months) Certified Product What is being certified Product Number, Manufacturer (Account), Category Product Certificate The issued certificate Auto-numbered Certificate Number, Status, Issue and Expiry Date, Product, Standard, Holder, Signatory, PDF (Base64), File Name, SHA-256, Generated On The Product Certification app: every certificate with its status, validity and when it was last generated. The certificate number is a Dataverse auto-number column with the format CPA-{DATETIMEUTC:yyyy}-{SEQNUM:5}, so numbering is guaranteed unique by the platform rather than by a person. The certificate holder defaults to the product’s manufacturer and can be overridden when a brand owner holds the certificate for a product someone else makes. 2. The renderer The PDF is drawn with SkiaSharp and the QR code with QRCoder, both open source. The same drawing code targets either a PDF page or a PNG bitmap, which means the image you check during development is exactly what the customer receives. Text is real, selectable text in embedded fonts, every graphic is a vector shape rather than an image, and long product names shrink to fit instead of overflowing the frame. CertificateRenderer.csC# public RenderedCertificate RenderPdf(CertificateRequest request) { Validate(request); using var output = new MemoryStream(); using (var document = SKDocument.CreatePdf(output, metadata)) { var canvas = document.BeginPage(842f, 595f); // A4 landscape, in points Draw(canvas, request); // same code paints the PNG preview document.EndPage(); document.Close(); } return new RenderedCertificate(output.ToArray(), FileNameFor(request.CertificateNumber)); } Vector from edge to edge, so quality never breaks There is not a single raster image in the certificate. Every line of text is real text in an embedded font, and the frame, the seal, the dividers and even the QR code are drawn as vector shapes. Zoom to 800%, print it on A3 or project it on a … Continue reading How a Sustainability Certification Nonprofit Automated Certificate Generation in Dynamics 365 →

Summary A home loan bank in the Maldives came to us needing legal, customer-facing reports for loan statements and overdue notices that had to reflect exact facility figures while matching the bank’s letterhead and legal wording. Traditional RDLC-based report development would have created significant IT dependency and delay for a document like this. Instead, our team used Word-based report layouts in Microsoft Dynamics 365 Business Central, which let us design the legal notice in a familiar document tool while Business Central handled populating it with live facility and customer data. We mapped the bank’s Business Central fields into a Word template, tested it against real facility scenarios, and delivered a working legal report in approximately two days, which is a turnaround that would traditionally take weeks with RDLC. This article walks through how we approached the build, using a sanitized sample report in place of the client’s confidential documents, and explains when we’d recommend Word over RDLC for a bank’s reporting needs. Table of Contents Introduction The Problem: IT Bottlenecks and Delayed Customer Documents The Word-Based Reporting Solution 3.1 How the Word-Based Approach Works 3.2 Creating the Word Template 3.3 Mapping Business Central Fields 3.4 Testing and Delivering the Report Sample Walkthrough: The Legal Report We Built Word Report vs. RDLC Report Time and Effort Comparison Why Banking Teams Benefit from Word Reports What Types of Banking Documents Work Best? Business Benefits When RDLC Is Still the Better Choice FAQs Conclusion About the Author Introduction Legal, customer-facing documents are one of the most sensitive parts of any lending business. A home loan bank in the Maldives came to us needing exactly this kind of document: a legal report covering a loan statement and overdue notice, which had to reflect exact facility figures, carry the correct legal clauses, and match the bank’s letterhead, all while pulling live data straight out of Business Central. Producing a document like this inside Microsoft Dynamics 365 Business Central can easily turn into a multi-week project if it’s built the traditional way. RDLC-based reporting usually means a developer has to build and maintain the report layout, write or modify code, configure data sources, and run several rounds of testing before the document is ready to go out to a customer. For a fairly standard legal document, like a loan statement or overdue notice, that kind of timeline is hard to justify. So instead of taking the client down the RDLC route, we proposed another option: Word-based report layouts. Word templates let us design the layout of the legal report in a tool the bank’s own team could later maintain, while Business Central handled populating it with the correct facility and customer data. The key idea: We designed the legal report’s layout and wording in Word, and let Business Central handle pulling in the correct facility data, so the client wasn’t locked into a developer for every future change. This article walks through how we built it, using a sanitized sample report in place of the client’s confidential documents, and explains how a report that would traditionally take weeks of RDLC development was designed, mapped, and delivered in approximately two days using a Word-based approach. The Problem: IT Bottlenecks and Delayed Customer Documents When the client first came to us, their existing experience with reporting was the same one many banks run into: a dependency between operations teams and technical teams that turns a simple document request into a long wait. The kind of request that used to happen internally looked something like this: “Hey, can we get a loan statement that shows the customer’s outstanding EMI, fines, and facility balance in one clean document?” “Sure, I’ll put in a ticket with IT.” [Two weeks later…] “The statement is almost done. It should be ready in another couple of weeks.” [Four weeks later…] “It’s finally here. Wait… the layout doesn’t match our branch letterhead format.” This kind of situation can happen when a relatively standard customer document becomes dependent on development resources. Why Do These Delays Happen? RDLC report layouts can require specialized development knowledge. Developers need time to configure data sources and implement the required reporting logic. Testing and troubleshooting can add additional development cycles. Small formatting changes such as a different overdue clause or a revised disclaimer may require technical assistance. Future modifications can place the document back into the development queue. Branch or collections staff may resort to manual, Word- or Excel-based workarounds while waiting for the official document. The result is a disconnect between the people who understand exactly what a legal notice or statement needs to say and the people responsible for implementing it in the system. The question we asked the client: What if your own operations or collections team could design and maintain these legal documents, using a tool they already know instead of relying on a developer for every change? The Word-Based Reporting Solution Microsoft Word was already familiar to the bank’s operations staff, so we proposed taking advantage of that. Business Central supports using Word templates directly as report layouts, which meant we didn’t need to build the legal report’s presentation through RDLC at all. Instead of developing the entire document presentation through RDLC, we designed the layout directly in Word and mapped Business Central’s available facility and customer data to the appropriate fields within that template. The solution: We used Word for the legal report’s presentation and Business Central for the facility data behind it. This separated document design from complex layout development and gave the client’s operations team greater control over formatting, tone, and compliance wording going forward. How We Approached the Build Our overall process was straightforward: Design the legal report layout using Microsoft Word. Add the required data fields to the Word template. Map those fields to the appropriate Business Central data. Run the report and let Business Central populate the template. Review the generated document with the client and adjust the layout where needed. The important distinction is that the document’s visual … Continue reading How We Built Legal Reports in Word on Business Central for a Home Loan Bank in the Maldives →

Site-Level Master Planning Summary Multi-plant manufacturers often run Planning Optimization as one global master plan that nets supply and demand across every site and warehouse together. That’s fine right up until each plant has its own planners, its own coverage rules, and its own idea of when on-hand stock should get consumed first. Microsoft’s “Plan for a single site or warehouse in Planning Optimization” feature (Feature Management, available from version 10.0.44) fixes this at the source: a master plan can now filter on stock dimensions (site, warehouse, batch), not just items, so the plan’s entire universe of supply, demand, and coverage data can be scoped to one location. We rolled this out for a North American truck manufacturer running several plants under a single legacy global plan. Splitting planning by site let each plant’s team run and own a plan tuned to what’s actually stocked and consumed there, without touching anyone else’s numbers. On this page 01The problem with one global plan 02What the feature actually changes 03Turning it on 04Building a plan filter on stock dimensions 05Two plants, two different plans 06Running the site-specific plan 07The catch: full filter only 08FAQs 09Conclusion The problem with one global plan A single master plan covering every plant is simple to set up and easy to explain: one run, one set of planned orders, one schedule. It’s also where the friction starts once a business runs more than one plant with different products, different suppliers, and different teams responsible for each. Planners at one plant end up looking at planned orders shaped in part by another plant’s on-hand corrections and forecast edits. A coverage code change made for one site’s parts can shift output for a site that has nothing to do with it. And because it’s one run, a data issue at any single plant (a bad forecast import, a stuck transaction) can delay the plan for every other plant waiting on the same run to finish. What the feature actually changes Master plans have always supported an item filter. What’s new is a Stock Dimensions table sitting alongside the Items table inside the plan filter, meaning a plan can now be scoped by Site, Warehouse, Batch number, or any other inventory dimension, not just by which items it considers. That distinction matters: this isn’t a coverage-code setting that changes how the plan computes numbers for items it already sees. It changes what the plan sees in the first place. The filter cascades to every planning input, including inventory transactions, forecasts, and item coverage settings like safety stock. Two plans with the same items can end up looking at entirely different supply and demand once their stock-dimension filters diverge. Turning it on The feature ships behind Feature Management, disabled by default: 1Open the Feature Management workspace and find Plan for a single site or warehouse in Planning Optimization. 2Enable it. No separate deployment step is needed; the new filter option appears immediately under Master Planning > Setup > Plans > Master Plans. Building a plan filter on stock dimensions With the feature enabled, scoping a plan to one plant is a setup task, not a code change: 1Open or create a master plan under Master Planning > Setup > Plans > Master Plans. 2Open Plan Filter. The Stock Dimensions table now appears alongside the Items table, and any inventory dimension is selectable as a filter field. 3Add the dimension that defines this plant’s scope (typically Site and Warehouse) and set the values that belong to it. Two plants, two different plans The client’s plants didn’t just need separate scopes; they needed separate policies. One plant runs standard assembly parts with no lot tracking; another runs batch-tracked, shelf-life-sensitive components that need on-hand stock consumed before anything else. The stock-dimension filter made both plans possible from the same master plan setup, configured independently: Plant A: Chassis Assembly Filter: Site = 1, Warehouse = WH-CHASSIS Includes on-hand stock and stock transactions No batch dimension; parts aren’t lot-tracked here Standard pegging behavior Plant B: Engine Components Filter: Site = 2, Warehouse = WH-ENGINE, plus Batch number Override Pegging Sequence enabled: on-hand consumed before other supply Shelf dates respected for batch-tracked, perishable-sensitive components Completely independent run schedule from Plant A Neither configuration affects the other. Plant B’s shelf-life logic never touches Plant A’s parts, and Plant A’s simpler setup isn’t forced to carry batch-level complexity it doesn’t need. “A single global plan optimizes for the business on paper. Separate site-level plans optimize for the planners who actually have to run them.” Running the site-specific plan From Master Planning > Run > Master Planning (or the Master Planning workspace), select the plan for the plant you want to run. The system generates planned orders only within that plan’s stock-dimension scope, and nothing from other sites enters the calculation. The standard item filter is still available at run time to narrow further, or it can be left blank to run every item within the plan’s scope. The catch: full filter only This is the detail that caught our planning team off guard the first time: stock-dimension scoping only works through the master plan’s own Plan Filter, not through the ad hoc runtime dialog filter. Open that runtime dialog and only the Items table is available; Site, Warehouse, and Batch simply aren’t selectable there. Practical implication: planners can’t improvise a one-off site-scoped run from the run dialog. Every site or warehouse that needs its own independent plan needs its own master plan record, configured ahead of time, not a flexible plan filtered differently run to run. FAQs 1Does this replace coverage groups or item coverage settings? No. Coverage codes still govern how the plan calculates replenishment for the items it sees. This feature governs what the plan sees in the first place: the stock-dimension filter applies before coverage logic runs. 2Can supply and demand for one item get double-counted across two site plans? Not if the filters are built to be mutually exclusive: different Site/Warehouse combinations with no … Continue reading How a Leading North American Commercial Vehicle Manufacturer Scoped Master Planning to a Single Site or Warehouse in Dynamics 365 Finance & Supply Chain Management →

Summary In Business Central, users may need to view relevant purchase invoice details directly from General Ledger Entries for better transaction visibility and traceability. This enhancement was implemented based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution in the Maldives. The solution enables purchase invoice details to be automatically captured against relevant General Ledger Entries for new transactions, while also providing an option to update previously posted entries. This helps finance users quickly identify the related invoice information without having to navigate through multiple pages or documents. Related Case Studies: Emirates Consortium – Customer Success HDFC PLC – D365 Business Central Integrated with Loan Management Table of Contents Introduction Understanding the Business Requirement The Challenge with Standard G/L Entry Descriptions Displaying vs. Storing the Description Designing the Solution Updating Historical G/L Entries Maintaining the Description for New Entries Implementation Approach Business Impact Frequently Asked Questions Conclusion Introduction In day-to-day financial operations, users often need to trace General Ledger Entries back to the original purchase transactions for verification, reconciliation, and reporting purposes. However, the standard General Ledger view may not always provide enough contextual information to quickly identify the details of the related purchase invoice. Based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution operating in the Maldives, an enhancement was introduced to make relevant purchase invoice details available directly within General Ledger Entries. The enhancement improves transaction visibility by capturing the relevant purchase invoice description against the General Ledger Entry. For newly posted transactions, the information can be populated automatically, while previously posted entries can be updated through a dedicated action. This approach reduces the need for users to navigate between General Ledger Entries and posted purchase invoices, making financial review and transaction tracing more convenient and efficient. Understanding the Business Requirement From a Finance user’s perspective, the requirement was straightforward: When a user reviews a G/L Entry, the Description should provide meaningful information about the transaction. The requirement needed to work for both existing historical entries and transactions posted after the customization was introduced. 1. Historical G/L Entries Business Central may already contain a significant number of posted G/L Entries. These historical records also needed to have the enhanced description populated. Updating these entries individually would not be practical. Therefore, the solution needed to provide a controlled way to update existing G/L Entries in bulk. 2. New G/L Entries For future transactions, the description should be populated automatically during the posting process so that users do not have to manually update the G/L Entry after posting. This resulted in two key requirements: Provide a mechanism to populate descriptions for historical G/L Entries. Automatically maintain the description for newly created G/L Entries. The Challenge with Standard G/L Entry Descriptions The first question during the design was whether the required description could simply be calculated when the G/L Entry page was opened. At the page level, a value can be calculated dynamically based on related information. This approach can be useful when the requirement is simply to display additional information to the user. However, there is an important distinction between displaying a calculated value and storing that value in the underlying G/L Entry record. A page-level calculated value does not automatically become part of the underlying G/L Entry data. Therefore, although a user may see the expected description on the page, the value may not be available in the same way for other processes that directly consume the G/L Entry data. Key Design Consideration The requirement was not only to display a meaningful description. The description needed to be persisted against the G/L Entry record. Displaying vs. Storing the Description This distinction became an important part of the solution design. 1. Page-Level Calculation A page-level calculation is useful when the requirement is simply: “Show this information to the user.” The value can be generated when the page is opened without modifying the underlying G/L Entry record. 2. Persisted G/L Entry Description For this requirement, the description needed to become part of the actual G/L Entry data. The solution therefore stores the generated description directly against the G/L Entry. G/L Entry → Determine Transaction Information → Generate Description → Store in G/L Entry This approach ensures that the description remains available after the page is closed and can be consumed by other Business Central processes that use the G/L Entry record. Designing the Solution The solution was designed around two scenarios: historical G/L Entries and newly created G/L Entries. 1. Historical G/L Entries A dedicated action is provided to populate the enhanced description for existing G/L Entries. This allows Finance users or authorized administrators to update historical records without having to process each entry individually. 2. Newly Created G/L Entries For newly posted transactions, the description is maintained as part of the G/L Entry creation process. This means that the enhancement does not depend on users remembering to manually update the description after every posting. Two-Part Approach Existing Entries: One-time controlled update. New Entries: Automatic description population during the posting process. Updating Historical G/L Entries Since the system may already contain historical G/L Entries, simply implementing the logic for future postings would leave existing records without the enhanced description. To address this, we introduced a one-time action that allows the required description to be generated and stored for historical entries. The process can be represented as: Existing G/L Entries → Run Update Action → Determine Required Information → Generate Description → Update G/L Entry This approach provides a practical way to bring historical records into the same structure used for newly posted transactions. Maintaining the Description for New Entries Updating historical records solves only one part of the requirement. The same description logic also needs to be applied to future G/L Entries. Therefore, the solution ensures that the description is generated and stored when the relevant G/L Entry is created. This avoids a situation where historical records have the … Continue reading Enhancing General Ledger Visibility with Purchase Invoice Details in Dynamics 365 Business Central for a Maldives Financial Institution and an Abu Dhabi-Based Diversified Holding Company →